Root cause of
babylonlabs-io/finality-provider#121. If
response is nil due to error, will cause panic

Closes #263. In particular,
- ensure `checkpointFinalizationTimeout` can never be changed in the
update params handler of the btccheckpoint module
- ensure `minUnbondingTime` can not be set to a value less than or equal
to `checkpointFinalizationTimeout` in the update params handler of the
btcstaking module
- allows `unbondingTime` of a delegation to be set to a value equals to
`minUnbondingTime`

This PR introduces the `ResumeFinalityProposal` and implements the
handler, which is part of
[ADR-32](babylonlabs-io/pm#95). This part is
quite independent and the algorithm of choosing finality providers to
jail can be implemented in the future

Updates cosmos math. 


[Issue](GHSA-7225-m954-23v7)

- fixes GHSA-p7mv-53f2-4cwj

(docker)resolve Dockerfile issue & fix CVEs

The bug is caused due to setting `params.MinStakingTime` to the
btcstaking module's keeper method `VerifyInclusionProofAndGetHeight`
other than `params.MinUnbondingTime`. In the fix, we remove
`minUnbondingTime` from the parameter list of
`VerifyInclusionProofAndGetHeight` as it should retrieve the parameter
within the method.

This PR also added comprehensive tests for
`VerifyInclusionProofAndGetHeight`

- EOI created delegations parameter version should be the some one for
given block range

With recent changes:
- enforcing that `min_unbonding_time` is always larger than
`checkpoint_finalization_timeout`
- changing `min_unbonding_time` to exact `unbonding_time`

`GetStatus` can now rely on `UnbondingTime` in delegation instead of
`checkpoint_finalization_timeout`

Closes #259. Using gauge is not easy to fix the issue as we don't know
the number of fps being jailed. Therefore, this PR fixed the issue by
adding a separate counter for unjailed fps.

- fixes genesis validation

- Fixes config linter config

- enables more linters from golang ci lint
- fixes some low hanging fruits

Adds initial scaffold for tests which enable full execution of the block
by comet-bft utilities:
- `BlockExecutor`

Those are test can be used in various scenarios:
- e2e application test asserting that after certain ordered operations,
we reached expected state
- deterministic execution tests i.e execute some random operations and
replay them and check that app hash matches
- early block execution tests (if we introduce other backends than
memdb)

- Helps to convert keys from pub key 

```shell
babylond debug pubkey-raw "A2h06lj/GAPW1RvJE3HU9yetMGCR9K7a+tcwwTYT8t7z"
Parsed key as secp256k1
Address: 3565AEBC1D0CF089A4C2B04500EFE5007701604E
JSON (base64): {"type":"tendermint/PubKeySecp256k1","value":"A2h06lj/GAPW1RvJE3HU9yetMGCR9K7a+tcwwTYT8t7z"}
Bech32 Acc: bbnpub1addwnpepqd58f6jcluvq84k4r0y3xuw57un66vrqj862akh66ucvzdsn7t00x5n57a8
Bech32 Validator Operator: bbnvaloperpub1addwnpepqd58f6jcluvq84k4r0y3xuw57un66vrqj862akh66ucvzdsn7t00x4p4spq
Bech32 Validator Consensus: 
BIP340 Hex: 036874ea58ff1803d6d51bc91371d4f727ad306091f4aedafad730c13613f2def3
```

Pr changes way how babylon choses parameters for pre-approval flow

- parameters will be chosen by BTC LC tip
- to avoid attacks in which somebody will first send tx to BTC and then
report it as EOI, additional validation during activation is added to
check that staking transaction is included after the BTC LC tip during
delegation creation.

Add determinism test for whole staking activation flow
pending/verified/active

Next steps:
- finalizing epochs
- finality provider voting and randomness registration

The voting power table is a map which causes random order of processing
jailing events. If more than one fps jailed at one block,
non-determinism could happen. The PR fixed this by introducing ordered
voting power table which retains the order from interating the
`votingPowerBbnBlockHeightStore`

- Add fuzzing test case for jailing being deterministc

- Move `PrivateSigner` to specific package
- Created vars for constant used Mod accounts in appparams

`EndBlocker` -> `BeginBlocker` in BeginBlocker section

- enable more lints

There has been an issue relative to
babylonlabs-io/finality-provider#231 and this pr
adds `MsgSetWithdrawAddress` to the necessary codec file plus adds it to
`types/msg.go`

- Add new structures to track BTC delegation rewards and lazily
distribute
- Add new event `BTCDelegationStatus_EXPIRED` for BTC delegations that
indicates a BTC delegation is no longer contributing to security
- Important files diff for review
  -  `proto/babylon/incentive/rewards.proto`
  -  `x/finality/keeper/power_dist_change.go`
  - `x/incentive/keeper/btc_staking_gauge.go`
  - `x/incentive/keeper/grpc_query.go`
  - `x/incentive/keeper/msg_server.go`
  - `x/incentive/keeper/reward_tracker.go`
  - `x/incentive/keeper/reward_tracker_store.go`
  - `x/btcstaking/keeper/btc_delegations.go`
  - `x/btcstaking/keeper/msg_server.go`
  - `x/btcstaking/types/btc_delegation.go`


## Benchmarks

Command to generate pprof `go tool pprof -http=:8080
http://localhost:6060/debug/pprof/profile\?seconds\=300`

- Main branch that iterates over delegations to distribute rewards with
163k BTC delegations, took 15.52s (13.1%) of the time during the
300seconds interval used to generate the pprof


![image](https://github.com/user-attachments/assets/83746927-87ec-421b-87ce-bae16c7c3000)

- Current branch `rafilx/improve-performance-btc-dist` with 100k BTC
delegations, took 6.73s (1.8%) of the time during the 300seconds
interval


![image](https://github.com/user-attachments/assets/ddf694a9-ed26-4a21-8fed-03a91d1e8450)


Note that the percentage of the time used that is ~7x lower should be
considered instead of the time, the benchmark from `main` was running in
the benchmark server 48 processors and 256GB of RAM while the one in the
current branch I run locally with 24 processors and 96GB of RAM.... So
the percentage of the time usage instead of seconds should be the one in
comparison

> Thanks @Lazar955  for help with benchmark
> The function used to show the difference is the `TallyBlocks` because
the `RewardBTCStaking` does not appear in the pprof of the current
branch demonstrating that the time spent there is negligible to the
overall period

Implements babylonlabs-io/pm#145 including:
- Rewards are calculated with a timeout `finality_sig_timeout`
- Rewards should not be assigned to finality providers that have not
voted for the block when calculating rewards.

- Upgrades parameters in upgrade for testnet launch

---------

Co-authored-by: Filippos Malandrakis <[email protected]>